Consume canonical TypeScript API exports - #1430
Conversation
Validates schema version 1 documents produced by `aspire sdk export` before the site reads them: unknown schema versions, the wrong language, missing package identity, duplicate stable IDs, declaration IDs that disagree on content, and blank signatures are all rejected at the input rather than surfacing as empty code blocks on a published page. The fixtures are unedited CLI output for one core and one integration package. Their combined declaration fragments type-check with noEmit and skipLibCheck disabled, which is what lets the site stop authoring shims. No signature conversion here; consumers still read the existing data. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 819baaf4-91c3-44ce-8004-3dbc9110f810
Regenerated with the producer fixes: augmentation item IDs now carry the contributing package so two integrations extending DistributedApplicationBuilder cannot collide, and CreateBuilderOptions gained the client-only throwOnPendingRejections property the module has always shipped. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 819baaf4-91c3-44ce-8004-3dbc9110f810
Frontend HTML artifact readyThe latest frontend build uploaded the This comment updates automatically when a new frontend build artifact is uploaded. |
There was a problem hiding this comment.
Pull request overview
Introduces a v1 “canonical TypeScript API export” contract (as produced by aspire sdk export --language typescript) into the frontend, along with fixtures and unit tests, so the site can validate/sort/dedupe/render the CLI-produced API surface instead of reconstructing TypeScript signatures locally.
Changes:
- Added
typescript-api-exportschema types + parser/validator + declaration concatenation helper. - Added raw CLI output fixtures for
Aspire.HostingandAspire.Hosting.Redis, plus unit tests validating the contract and cross-package invariants. - Re-exported the canonical schema types from
ts-modules.tsto provide a single import path for consumers during migration.
Reviewed changes
Copilot reviewed 4 out of 5 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/frontend/src/schemas/typescript-api-export.ts | Adds v1 schema types, validation, loader, and declaration concatenation. |
| src/frontend/src/utils/ts-modules.ts | Type-only re-export of canonical export types for downstream imports. |
| src/frontend/tests/unit/typescript-api-export.vitest.test.ts | Adds validation tests + a tsc --noEmit --strict typecheck over concatenated fragments. |
| src/frontend/tests/fixtures/typescript-api-export/Aspire.Hosting.Redis.api.json | Adds raw CLI export fixture for the Redis integration package. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| let output = ''; | ||
| try { | ||
| execFileSync(process.execPath, [tsc, '--project', tsconfig], { encoding: 'utf8' }); | ||
| } catch (error) { | ||
| output = (error as { stdout?: string }).stdout ?? String(error); | ||
| } |
Draft. Consumer half of microsoft/aspire#19032 — tracking #17608.
Today
AtsJsonGeneratorreconstructs TypeScript signatures on the site side: options-overload synthesis, C# inheritance borrowing, container-base inference, missing-declaration stubs. It's a second implementation of the TypeScript projection that lives in the wrong repo, and it drifts from what the generator actually emits. That's the bug behind #17608.The plan is for the CLI to hand us the API surface for an exact
Name@Versionand for this repo to do nothing but validate, sort, dedupe, and write.What's in the draft so far
The schema v1 contract and the fixtures, so the switchover has something to land against:
src/schemas/typescript-api-export.ts— parser/validator, typed loader,concatenateDeclarationstests/fixtures/typescript-api-export/*.json— uneditedaspire sdk exportoutput forAspire.HostingandAspire.Hosting.Redistsc --noEmit --strictwithskipLibCheckoffThe fixtures are deliberately raw CLI output, not hand-tidied — if the producer drifts, these tests are what catches it. That already paid off once: the augmentation ownership test here caught
addRedisshipping asinterface:DistributedApplicationBuilderowned byAspire.Hosting.Redis, which collides with core's item ID. Fixed on the producer side.Still to come on this branch
update-ts-api.tsontoaspire sdk exportand deleteAtsJsonGeneratorgenerate-twoslash-types.tsto validation + dedupe + writenormalize-generated-api-data.tsKeeping it a draft until microsoft/aspire#19032 is in and there's a CLI on a feed CI can restore — the refresh workflow can't run against a
sdk exportthat isn't published yet.Testing
328/328 unit tests, eslint clean.